Pull Requestのやり取りを減らすには
train.icon
最後に、コードの読みやすさは時代とともに進化するので、キャッチアップをわすれずに楽しもう！
ここは時代とともに変化というより、「読みやすさを考慮してこない」という前時代的な慣習が許されなくなってきている、が実態かなって気がするsta.icon
昔はリーダビリティなんて概念はなかったし、意識もされなかったので「誰かが書いたクソースをがんばって読む」という根性論精神論的なところがあった
それは不毛なので「そもそも読みやすいコード書きましょうよ」となっていった
どころか「いくら優秀でも読みにくいコードしか書けない奴は要らない」さえも起こりうる
sta.icon
ガチ勢になると「テストコード書いてこれ通らないと話にならないね」「まずは通してからだ」を組み込む
次に牛尾さんも言うてるけどリーダビリティ意識しろ
コードは他の人も読み書きするものなので、「出来る奴」のクソースはキツイ でもなー、ここ難しいよなsta.icon
出来る奴はリーダビリティを意識できない（この2つの才能は相反する）
そういう奴を何とかする方法は2つじゃない？
1 レビューでしつこく指摘して直させる
2 関わらせない
たとえばプロトタイプだけつくらせるとか、そういう分担にする
この辺上手いのがmasuakishoraku.iconだよね
masui.iconはできる奴だけど、リーダビリティはあまりない
別にけなしてるわけじゃなくて、上にも書いたけど2つの才能は相反する。masui.iconに限らず前者がある人は後者は無い。
仮にmasui.iconが製品コードをガッツリ書くとしたら現場は苦しいと思う
でもmasui.iconはそんなことをせず、最初のプロト、0→1をつくって見せるところに専念している
これくらいなら量はたかが知れてるからあまりリーダビリティなくても読める
（ついでに言えばmasui.iconはリーダビリティなコードを書く～、みたいなことは関心なさそう）
実際ガリガリ書いてるのはshokai.iconだよね
が、下手な組織だとmasui.iconに1→3や3→10のコードを書かせる、みたいなことをするんですわsta.icon
見た感じ、牛尾さんも出来る奴って感じがするから、2の方が良いかもしれないね
あとは「一番詳しいのは自分なんだから自分が主張してねじ伏せろ」かな
お前のコメントは甘いね。俺がここをこうしているのはこうこうこういう理由からなんだよ、みたいな主張をしてねじ伏せる
まあここで「だったらそれが読み取れるようにリーダビリティ担保せえよ」ってなるけど
もちろんコードやコメントで表現できることなどたかが知れている
ドキュメントに書く？どこに、どういう風に？となる
そして上手く書けたとしても、ドキュメント量が膨大になって結局皆がついてこれなくなる
いちいち読まなくなる。みんな忙しいし、エンジニア（特に外資など優秀な奴がいるところ）は文章説明読みたがらないところがある（と思う）しsta.icon
難しいよねー